前言

今天就將討論Cluster有哪些Gateway模式的選擇。

Kubernetes Ingress

Kubernetes Ingress可以當作Cluster流量入口，但存在兩個問題：

Kubernetes Ingress Controller是獨立在Service Mesh(Istio)之外的，需要單獨采用Ingress rule進行配置，導致Kubernetes Cluster和Service Mesh存在兩套互相獨立的路由規則配置，導致後續維運跟管理都會有很高的複雜度。
Kubernetes Ingress的功能也比較弱，不能在入口處實現和Service Mesh類似的路由規則，也不具備Service Mesh Sidecar Proxy的其它功能，導致難以從整體上為系統實現藍綠部署、分散式Tracing等功能。

Istio Gateway

Ingress和Service Mesh配置不同，甚至有許多重疊的功能，因此Istio後來的版本都有內建Istio-Gateway，Istio-Gateway代替Kubernetes Ingress來當作Cluster入口。

Istio Gateway本身只能配置L4到L6的功能，例如Expose Port，TLS設置等；但Gateway可以綁定一個VirtualService，在VirtualService 中可以配置L7 Route Rule，這些L7 Route Rule可以根據服務版本對請求進行分流，故障注入，HTTP重定向，HTTP重寫等所有Servcie Mesh(Istio)支持的Route Rule。

Gateway和VirtualService用於表示Istio Ingress的配置模型，Istio Ingress則采用了和Sidecar相同的Envoy proxy。

通過該方式，Istio同時控制了入口和內部的sidecar代理。這些配置包括路由規則，策略檢查、Telementry收集以及其他服務管理功能。

API Gateway

采用Gateway和VirtualService實現的Istio Ingress Gateway提供了Kubernetes Cluster入口功能。但對於一個服務來說，Istio Ingress Gateway除了基礎功能之外，還有一些其他的需求，例如：

• Authentication & Authorization for users / 3rd-party systems
• Enforce SLAs for different users / 3rd-party systems
• Data transformation / translation
• API lifecycle management
• Rate limiting
• Billing
• Other customized requirements ...

API Gateway有很大一部分需要根據不同的需求進行客製化，目前看來暫時不可能被納入Kubernetes Ingress或者Istio Gateway的標準中。因此為了滿足這些需求，湧現出了各類不同的Kubernetes Ingress Controller以及Istio Ingress Gateway實作，包括Ambassador，Kong， Traefik，Solo等。

這些API Gateway實現在提供基礎的Kubernetes Ingress能力的同時，提供了強大的API Gateway功能，但由於缺少統一的標準，這些擴展實現之間相互之間並不兼容。而且遺憾的是，目前這些Ingress controller都還沒有正式提供和Istio整合的能力，但是可以直接使用這些API Gateway達到超越Kubernetes Ingress Controller基本的功能。

API Gateway + Sidecar Proxy as the External Traffic Entrance for a Service Mesh

在目前難以找到一個同時具備API Gateway和Isito Ingress Gateway能力的API Gateway情況下，一個可行的方案是使用API Gateway和Sidecar Proxy一起為Service Mesh提供Kubernetes Cluster入口。

由於API Gateway已經具備L7 Gateway的功能，Service Mesh Ingress Gateway中的Sidecar只需要提供VirtualService的路由能力，並不需要提供Gateway的能力，因此采用Sidecar Proxy即可。Kubernetes Cluster入口處的Sidecar Proxy和Service Mesh內部Pod中的Sidecar Proxy的唯一一點差別是：該Sidecar只接管API Gateway向Service Mesh內部的流量，並不接管外部流向API Gateway的流量；而Pod中的Sidecar需要接管進入Pod所有流量。

采用API Gateway和Sidecar Proxy一起作為服務網格的流量入口，是目前Service Mesh API Gateway的一個不錯方案。

性能方面的考慮：從上圖可以看到，外部請求的處理流程在入口處增加了Sidecar Proxy，因此會帶來些許的性能損耗，但這些損耗是完全可以接受的。

對於請求延遲而言，在Service Mesh中，一個外部請求本來就要經過較多的處理，在Ingress Controller增加一個Proxy對整體的延遲，影響基本忽略不計，而且對於絕大多數Service來說，Forward的時間比例本來就很小，99%的耗時都在業務邏輯。如果整個系統對於增加Proxy會導致延遲，則建議重新考慮是否需要微服務架構和Service Mesh。

對於吞吐量而言，如果Kubernetes Cluster的API Gateway吞吐量存在瓶頸，則可以通過對API Gateway + Sidecar Proxy組成的Kubernets Ingress Controller進行水平擴展，來進行Load Balancer，以提高Kubernets Cluster的吞吐量。最好的方式就是針對API Gateway采用NodePort或LoadBalancer的方式提供，再添加External Load Balancer。

結語

今天比較著墨在外部請求如何能夠更有效的選擇，好的Gateway方式。

圖片來源

Service